Forward Secrecy is one of the cryptographic goals we strive to achieve throughout Signal - if you sent a message last year, that message has since been deleted (due to disappearing messages, manual deletion, etc), then your device is compromised today, how do we disallow the attacker from accessing that old message? While the message is being sent and received, we utilize our ratcheting protocols, but what about for backups? A backup must use a predefined static key, or users wouldn’t be able to restore their old backups in the case where their devices were lost or destroyed. But reusing the same key for all backups negates forward secrecy - an attacker could have access to copies of old backups, and on learning the static key they could decrypt all past backups and get access to your old messages.

Signal already has a system in place for account recovery that uses a predefined key to access secret material, called Secure Value Recovery. In this system, a collection of remote enclaves encrypts and stores a set of secrets and associated PINs. A user can access the secret by providing their PIN, and with that secret they can then prove to Signal’s other servers that they’re associated with a particular account and regain access to it. When we looked at the problem of Backup Forward Secrecy, we observed multiple similarities. So, we used a new deployment of our existing system to store secret material that could be used to recreate a Forward Secrecy Token - a secret that can be mixed into a backup’s encryption secret on a per-backup basis, then rewritten once a new backup is created. By effectively storing forward secrecy tokens in a secure, rewritable database, we’re able to forget old secrets by overwriting them with new ones, preserving Forward Secrecy.

In this talk, we’ll discuss the problem of Forward Secrecy in Backups, the decision to reuse existing infrastructure in a new way rather than building something new from scratch, and the integration of the resulting Forward Secrecy Tokens (FSTs) into the encryption of backups that allows the property of Forward Secrecy to be attained. We’ll discuss the protocols for storing, retrieving, overwriting, and deleting FSTs, as well as the way that FSTs are integrated into the encryption of stored backups. We’ll also discuss the ways we’ve created a system where a newly generated backup can be stored remotely along with its associated FST, such that a failure during any step still allows for a recent backup to be restored.

plus-circle Add Review

comment

Reviews